Skip to content

fix(permission): read uses worktree-relative path patterns#26527

Closed
BennD wants to merge 1 commit intoanomalyco:devfrom
BennD:fix/permission-read-relative-pattern
Closed

fix(permission): read uses worktree-relative path patterns#26527
BennD wants to merge 1 commit intoanomalyco:devfrom
BennD:fix/permission-read-relative-pattern

Conversation

@BennD
Copy link
Copy Markdown

@BennD BennD commented May 9, 2026

Issue for this PR

Closes #26524

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

read was evaluating permission rules against the absolute file path, while edit / write / apply_patch already use the worktree-relative path. So "read": { "src/*": "deny" } silently failed to match the same files that "edit": { "src/*": "deny" } would deny.

This PR aligns read with the other file tools — emits path.relative(instance.worktree, filepath).replaceAll("\\", "/") as the pattern. Same shape apply_patch already uses.

Out of scope (tracked as follow-ups):

  • Non-git worktree edge case (worktree === "/" makes path.relative produce nearly-absolute paths). Affects all relative-path tools, not just read.
  • Forward-slash normalization in edit/write (currently masked by Wildcard.match doing the same thing at match time). Will fold into a small helper-extraction refactor.

How did you verify your code works?

  • bun typecheck from packages/opencode — clean
  • bun test test/tool/read.test.ts — 40/40 pass (3 new tests for the relative-pattern behavior, 1 updated Windows assertion)
  • bun test test/permission test/tool — 365/365 pass
  • The new "relative read patterns match worktree-relative deny rules from config" test directly feeds a config-derived ruleset through Permission.evaluate against the patterns the read tool emits, asserting deny.
  • Manual smoke test with a built --single binary against a temp project containing permission: { read: { "*": "allow", "src/*": "deny" }, edit: { "*": "allow", "src/*": "deny" } }. Before the fix, only edit denied src/secret.ts; after the fix, both read and edit deny it as configured.

Behavior change for users

Anyone who configured read with absolute paths (e.g. "read": { "/home/me/proj/secrets/**": "deny" }) will need to rewrite as worktree-relative ("secrets/**": "deny"). This was the only way to make read rules match anything specific before this fix; the relative form matches the docs and how the other file tools work.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

read evaluated permission rules against the absolute file path while
edit/write/apply_patch use path.relative(instance.worktree, filePath).
A user rule like "read": { "src/*": "deny" } silently failed to match
even though the equivalent "edit" rule worked.

Match the shape apply_patch already uses, including forward-slash
normalization. Updates the Windows assertion in read.test.ts and adds
three tests covering the relative pattern, slash normalization, and
end-to-end config rule matching.

Closes anomalyco#26524
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 9, 2026

The following comment was made by an LLM, it may be inaccurate:

Based on my search results, I found a potentially related PR:

PR #24320: fix(read): match project-relative permissions

This PR is directly related as it also addresses the read tool's permission matching with project/worktree-relative paths. It appears to be a prior attempt or related work on aligning the read tool's path evaluation with how other file tools (like edit/write) handle relative path patterns.

The current PR (#26527) builds on this area by ensuring read uses the same worktree-relative path pattern evaluation as edit/write/apply_patch, which aligns with the goals of the earlier PR #24320.

@BennD
Copy link
Copy Markdown
Author

BennD commented May 10, 2026

Superseded by #26583, which shipped essentially the same fix. Closing.

@BennD BennD closed this May 10, 2026
@BennD BennD deleted the fix/permission-read-relative-pattern branch May 10, 2026 09:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

read permission patterns are evaluated as absolute paths, not worktree-relative like edit/write/apply_patch

1 participant